Suggested by @xFrednet and @matthiaskrgr.

…ubtree-update

Have the lint trigger even if `Self` has generic lifetime parameters.

```rs
impl<'a> Foo<'a> {
    type Item = Foo<'a>; // Can be replaced with Self

    fn new() -> Self {
        Foo { // No lifetime, but they are inferred to be that of Self
              // Can be replaced as well
            ...
        }
    }

    // Don't replace `Foo<'b>`, the lifetime is different!
    fn eq<'b>(self, other: Foo<'b>) -> bool {
        ..
    }
```

Fixes rust-lang#12381

Add asm goto support to `asm!`

Tracking issue: rust-lang#119364

This PR implements asm-goto support, using the syntax described in "future possibilities" section of [RFC2873](https://rust-lang.github.io/rfcs/2873-inline-asm.html#asm-goto).

Currently I have only implemented the `label` part, not the `fallthrough` part (i.e. fallthrough is implicit). This doesn't reduce the expressive though, since you can use label-break to get arbitrary control flow or simply set a value and rely on jump threading optimisation to get the desired control flow. I can add that later if deemed necessary.

r? ``@Amanieu``
cc ``@ojeda``

fix [`missing_docs_in_private_items`] on some proc macros

fixes: rust-lang#12197

---

changelog: [`missing_docs_in_private_items`] support manually search for docs as fallback method

…enkov

Refactor pre-getopts command line argument handling

Rebased version of rust-lang#111658. I've also fixed the Windows CI failure (although I don't have access to Windows to test it myself).

Lint singleton gaps after exclusive ranges

In the discussion to stabilize exclusive range patterns (rust-lang#37854), it has often come up that they're likely to cause off-by-one mistakes. We already have the `overlapping_range_endpoints` lint, so I [proposed](rust-lang#37854 (comment)) a lint to catch the complementary mistake.

This PR adds a new `non_contiguous_range_endpoints` lint that catches likely off-by-one errors with exclusive range patterns. Here's the idea (see the test file for more examples):
```rust
match x {
    0..10 => ..., // WARN: this range doesn't match `10_u8` because `..` is an exclusive range
    11..20 => ..., // this could appear to continue range `0_u8..10_u8`, but `10_u8` isn't matched by either of them
    _ => ...,
}
// help: use an inclusive range instead: `0_u8..=10_u8`
```

More precisely: for any exclusive range `lo..hi`, if `hi+1` is matched by another range but `hi` isn't, we suggest writing an inclusive range `lo..=hi` instead. We also catch `lo..T::MAX`.

New lint `const_is_empty`

This lint detects calls to `.is_empty()` on an entity initialized from a string literal and flag them as suspicious. To avoid triggering on macros called from generated code, it checks that the `.is_empty()` receiver, the call itself and the initialization come from the same context.

Fixes rust-lang#12307

changelog: [`const_is_empty`]: new lint

… `duplicated_attributes`

Rustup

r? `@ghost`

changelog: none

…ubtree-update

std::net: adding acceptfilter feature for netbsd/freebsd.

similar to linux's ext deferaccept, to filter incoming connections before accept.

…lstrieb

Doc Guarantee: BTree(Set|Map):  `IntoIter` Iterate in Sorted by key Order

This Doc-only PR adds text to the IntoIterator implementation and IntoIter type for both BTreeMap and BTreeSet that states that the returned items will be in sorted-by-key order, this is a guarantee that is made by the iter() and iter_mut() methods of BTreeMap/Set and BTreeMap respectively, but not on into_iter methods or types.

I don't know how the IntoIter iteration would not be sorted by key, and I would like to rely on that behavior for my prefix_array crate.

The text appended to IntoIter documentation is based on each types respective iter() method documentation, as is the text used in the IntoIterator documentation; they are slightly inconsistent between Set/Map, but they are consistent within their own types documentation.

…und-tests, r=lcnr

Add tests for shortcomings of associated type bounds

Adds the test in rust-lang#122791 (comment)

Turns out that rust-lang#121123 is what breaks `tests/ui/associated-type-bounds/cant-see-copy-bound-from-child-rigid.rs` (passes on nightly), but given that associated type bounds haven't landed anywhere yet, I'm happy with breaking it.

This is unrelated to rust-lang#122791, which just needed that original commit e6b64c6 stacked on top of it so that it wouldn't have tests failing.

r? lcnr

…iter, r=compiler-errors

Implement `FusedIterator` for `gen` block

cc rust-lang#117078

… r=clubby789

make failure logs less verbose

Resolves rust-lang#122706

Logs without verbose flag:

![image](https://github.com/rust-lang/rust/assets/39852038/f2fc2d35-0954-44b0-bedc-045afedaabe8)

Logs with verbose flag:

![image](https://github.com/rust-lang/rust/assets/39852038/b9308655-ad31-4527-a1be-5a62a78ac469)

I decided to exclude command from the log since it's already included in verbose mode.

cc ``@Nilstrieb``

…enkov

add test for rust-lang#122549

Fixes rust-lang#122549

…ings-to-prevent-incremental-protests, r=matthiaskrgr

Avoid noop rewrite of issues.txt

Fixes rust-lang#122834

r? ``@matthiaskrgr``

…, r=lcnr

Split out `PredicatePolarity` from `ImplPolarity`

Because having to deal with a third `Reservation` level in all the trait solver code is kind of weird.

r? `@lcnr` or `@oli-obk`

…matthiaskrgr

Clippy subtree update

r? `@Manishearth`